home *** CD-ROM | disk | FTP | other *** search
/ Deutsche Edition 1 / Deutsche Edition 1.iso / amok / amok_lha / amok49.lha / RCT / RCT.dok < prev    next >
Text File  |  1993-08-15  |  6KB  |  142 lines
  1. (*
  2.   :Program.       RCT.mod
  3.   :Contents.      RCT exports functions to use RCT-generated
  4.   :Contents.      c-source-code from Amiga-Oberon
  5.   :Author.        Volker Rudolph
  6.   :Address.       Lettow-Vorbeck-Str. 11 / 6750 Kaiserslautern 26
  7.   :Phone.         06301/8566
  8.   :Copyright.     Freeware
  9.   :Language.      Oberon / Assembler
  10.   :Translator.    Oberon V1.17.1 / A68k (Freeware)
  11.   :History.       Version 1.0 - first public release
  12.   :Bugs.          No known bugs.
  13. *)
  14.  
  15. Es gibt mittlerweile einige Tools mit denen man komfortabel Intuition-
  16. Objekte wie Screens, Windows, Requester und Menüs erzeugen kann, z.B.
  17. Power-Windows und RCT. Leider generieren diese Programme nur
  18. Quelltexte für C oder Assembler, nicht aber für Oberon. Glücklicher-
  19. weise bietet Amiga-Oberon aber die Möglichkeit, Programmteile aus
  20. anderen Programmiersprachen zu Oberon-Modulen dazuzulinken. Da ich
  21. stolzer Besitzer des RCT (Resource-Construction-Tool) bin, habe ich
  22. mich einmal damit beschäftigt, RCT-generierte C-Quelltexte in Oberon
  23. zu verwenden. Es gab dabei einige kleine Probleme, die ich mit dem
  24. Modul RCT gelöst habe. Ich habe mich für C entschieden, da die
  25. Quelltexte kürzer und klarer aufgebaut sind als Assembler-Quelltexte.
  26. Als C-Compiler habe ich den DICE von Matt Dillon benutzt (Shareware).
  27.  
  28. Allgemeines:
  29.   Das RCT erzeugt C-Quelltexte, die aus vorinitialisierten Records und
  30.   Arrays, aber auch aus Prozeduren bestehen. Mit den vorinitiali-
  31.   sierten Daten gibt es keine Probleme, aber Prozeduren werden in C
  32.   etwas anders aufgerufen als in Oberon. Der Unterschied liegt in der
  33.   Parameterübergabe und in der Bereinigung des Stacks nach dem
  34.   Prozeduraufruf. In Oberon werden die Argumente eines Prozedur-
  35.   aufrufs von links nach rechts auf den Stack gelegt, das heißt das
  36.   erste Argument zuerst, dann das nächste usw. . In C ist es genau
  37.   andersherum, hier wird das letzte Argument zuerst auf den Stack
  38.   gelegt. Dieser Unterschied interessiert hier aber nicht, da die von
  39.   RCT erzeugten Prozeduren alle nur ein Argument haben. Wesentlich
  40.   störender ist der Unterschied in der Stackbereinigung. In Oberon
  41.   wird der Stackbereich der für die Argumente der Prozedur gebraucht
  42.   wurde, von der Prozedur selbst wieder freigegeben, in C wird das von
  43.   der aufrufenden Funktion erledigt. Wenn man also eine C-Prozedur
  44.   direkt aufrufen würde, würde der Stack gründlich durcheinander
  45.   geraten und das hätte dann natürlich den Programmabsturz zur Folge.
  46.   Dieses Problem löst die Funktion CCall() aus dem Modul RCT. Ihr
  47.   übergibt man die C-Funktion und das Funktions-Argument und CCall
  48.   kümmert sich dann um den Stack. Ein anderes Problem beim RCT sind
  49.   Image-Strukturen. Die Bilddaten für die Images müssen natürlich im
  50.   Chip-Memory stehen, aber RCT kümmert das überhaupt nicht. Die
  51.   Bilddaten (im C-Source 'reqimgbitblk') werden als normale Konstanten
  52.   definiert und dann auch mit den anderen Daten ins Fast-Memory
  53.   geladen (falls vorhanden). Es ist natürlich keine Lösung vor dem
  54.   Programmstart jedes mal NoFastMem zu starten, deshalb gibt es die
  55.   Prozedur ImagesToChip, die diese Image-Strukturen kopiert.
  56.  
  57. ›33mProzedur-Beschreibungen:›31m
  58.  
  59. Aufruf einer C-Funktion:
  60.   PROCEDURE CCall(cProc:CProcType;arg:LONGINT):LONGINT;
  61.  
  62.   Eingabe:
  63.     cProc:    C-Funktion (siehe Beispiel Req.mod)
  64.     arg:      Argument der C-Funktion
  65.  
  66.   Returnwert: Returnwert der C-Funktion
  67.  
  68. PROCEDURE ImagesToChip*(images:I.ImagePtr;imageNum:INTEGER):BOOLEAN;
  69.  
  70.   Eingabe:
  71.     images:   Pointer auf die Image-Records im C-Quelltext
  72.     imageNum: Anzahl der Image-Records
  73.  
  74.   Returnwert: FALSE, falls nicht genug Chip-Memory frei war.
  75.  
  76.  
  77. Wie man nun RCT-generierte Quelltexte in eigenen Programmen verwendet,
  78. sieht man am Besten an einem Schritt-für-Schritt-Beispiel. Ich habe
  79. mit dem RCT ein Menü und einen Requester entworfen und mit den
  80. folgenden Befehlen kann man sie in ein eigenes Programm einbinden. Die
  81. Datei heißt im Beispiel Req.RCT, man kann sie aber natürlich beliebig
  82. benennen.
  83.  
  84. 1.  Mit RCT einen Requester und ein Menü entwerfen und als REQ.RCT
  85.     abspeichern. Der RCT erzeugt zwei Dateien: REQ.RCT und REQ.DFN
  86.  
  87. 2.  Mit RCT_TO_ASCII C-Quelltext generieren lassen. RCT_TO_ASCII
  88.     erzeugt REQ.c und REQ.h. In Req.h stehen die IDs der Gadgets und
  89.     Requester.
  90.  
  91. 3.  Man schreibt sich ein Modul, in dem man alle '#define'-statements
  92.     in REQ.h als Konstanten definiert. Alle Variablen aus REQ.C, auf
  93.     die man im Oberon-Programm zugreifen will, müssen in der Form
  94.     ›33name["_cname"]:type›31m definiert werden. Dabei ist zu
  95.     beachten, daß der C-Compiler vor Variablen und Prozeduren einen
  96.     Unterstrich '_' einfügt. Z.B. bekommt die Variable 'reqmenu' aus
  97.     dem C-Quelltext das Label '_reqmenu'.
  98.     Für jeden entworfenen Requester generiert RCT eine Aufrufprozedur.
  99.     Man muß sie als
  100.     ›33mPROCEDURE Name{"label"}(window:LONGINT):LONGINT;›31m
  101.     definieren. Diese Prozedur kann man dann mit RCT.CCall() aufrufen.
  102.  
  103.     Ein Beispiel für eine solche Datei ist das Modul ReqInterface.
  104.  
  105. 4.  Man schreibt sich ein Programm um die definierten Datenstrukturen
  106.     zu testen (siehe RCTTest.mod) .
  107.  
  108. 5.  Man kompiliert mit einem C-Compiler den C-Quelltext. Z.B.
  109.     > ›33mdcc -mD -c REQ.c -o obj/REQ.o›31m
  110.     Die Option '-mD' bewirkt beim DICE, daß das große Datenmodell
  111.     (Large-Data) verwendet wird. Das kleine Datenmodell (Small-Data)
  112.     ist nicht zum kleinen Datenmodell von Amiga-Oberon kompatibel und
  113.     kann deshalb nicht verwendet werden. Dies gilt auch bei Verwendung
  114.     anderer C-Compiler wie SAS-C oder North-C (beide nicht getestet).
  115.     Aztec-C ist ungeeignet, da der erzeugte Object-Code nicht BLink-
  116.     kompatibel ist.
  117.  
  118. 6.  Man kompiliert und linkt das ganze Programm. Z.B.
  119.     > ›33mOMake c-md RCTTest DONTLINK›31m
  120.     > ›33mOLink RCTTest -smd obj obj/Req.o›31m
  121.     Man muß OLink extra aufrufen, da die C-Objektdatei Req.o von OLink
  122.     nicht gefunden wird und deshalb explizit angegeben werden muß.
  123.  
  124.  
  125. Das Modul RCT besteht aus einem Oberon und einem Assemblerteil. Im
  126. Assemblerteil werden dem RCT-generierten C-Programm die benötigten
  127. Variablen und Prozeduren zur Verfügung gestellt. Zum Kompilieren bzw.
  128. Assemblieren des Moduls muß man folgende Befehle eingeben:
  129. > ›33ma68ktxt/RCT.s -oRAM:RCT.o›31m
  130. > ›33mOberon -md RCT.mod›31m
  131. > ›33mJoinobj/RCT.objs RAM:RCT.o as RAM:RCT.objs›31m
  132. > ›33mCopy RAM:RCT.objs obj›31m
  133.  
  134. Ich habe bei allen Beispielen das kleine Code- und das kleine
  135. Datenmodell gewählt, aber die großen Modelle müßten auch
  136. funktionieren.
  137.  
  138. Viel Spaß
  139.  
  140.   Volker.
  141.  
  142.